Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Transaction blocks

Transactions in Progress are scoped to blocks. You’re already familiar with the concept of building procedures up out of nested blocks of procedural statements and how record scoping is affected by those blocks. Transaction scoping works in much the same way and is closely tied to the scoping of records to blocks. Some blocks in Progress procedures are transaction blocks and some aren’t, according to these rules:

You can explicitly include the TRANSACTION keyword on a FOR EACH or REPEAT block, or on a DO block with the optional error-handling phrase beginning ON ERROR. Any block that uses the TRANSACTION keyword becomes a transaction block.
Any block that directly updates the database or directly reads records with EXCLUSIVE-LOCK likewise becomes a transaction block. This can be a procedure block, a trigger block, or each iteration of a DO, FOR EACH, or REPEAT block.

A direct database update can be, for example, a CREATE, DELETE, or ASSIGN statement. A block is said to be directly reading records with EXCLUSIVE-LOCK if at least one of the FIND or FOR EACH statements that has the EXCLUSIVE-LOCK keyword is not embedded in an inner block enclosed within the block in question.

A DO block without the NO-ERROR phrase does not automatically have the transaction property. Also, a procedure that would start a transaction on its own can run from another procedure that has already started a transaction. In this case, you enclose the called procedure in the larger transaction of the calling procedure. Once a transaction is started, all database changes are part of that transaction until it ends. Each user or session can have just one active transaction at a time. If one transaction block is nested within another, the inner block forms a subtransaction that you can programmatically undo if it causes an error or fails some validation constraint. You’ll learn about subtransactions later in Chapter 17, " Managing Transactions."